Split the project upload and update handlers into named steps - #72

handleUploadProjectLocked and handleUpdateProjectLocked now read as a
sequence of small steps that each return a Refusal record, so every
early return keeps its status, body and order. Upload state moves
through UploadRequest, UploadHistory, UploadArchive and UploadRollback
records; update state through OwnerTransfer. Pure decisions live in
policy files with tests, and the request, refusal and editor scope
helpers are shared by both handlers.

refused() turned any status other than 400, 403 and 404 into a 500.
Give 500 its own branch and send any other status as it is, with an
ok: false body. No current refusal uses another status, so responses
are unchanged.

Every source file lists its exports after its imports; project-update.osl
had none. Its OwnerTransfer record moves to project-update-policy.osl,
next to how the upload step records sit in project-upload-policy.osl.

project-upload-policy.osl was collecting helpers that are not upload
policy. keysNotIn, storedWorkspaceLayers, replacedWorkspaceKeys and
projectFilesErrorBody move to project-upload-publish.osl, and megabytes
with the three size failure helpers move to project-upload-files.osl.
Their tests move into new test files beside those sources.

The split carried three comments over unchanged. New code here has no
comments, and the function and parameter names already say what they
described.

The smoke test masked far more than was volatile. Its key pattern was
case-insensitive, so suffix rules also hid dataFormat, allowedItems,
item and product ids, credit URLs, jsonKey and workspaceKey, and sizes
were rounded to KiB, which would hide a character count used as a byte
count.

Mask only named volatile keys (tokens, view keys, timestamps, history
sizes, notification ids and the history-sized quota figures), random
access keys in URLs and embedded hashes and times. Sizes are compared
exactly, and staged chunk sizes are checked against the bytes sent.
Every successful upload and update now records the stored project, and
the blob inventory lists the exact asset and project JSON names. A
non-ASCII project and description tell characters from bytes.

Add the refusals that can be reached offline: a corrupt sb3 that only
fails to decompress, an oversized asset (project_too_large), a full
Rotur storage (storage_full, from a fake storage ledger that refuses one
user), a missing worktree asset, history that does not descend from the
saved head, a merge tree that cannot be merged, and a pull whose source
remix was deleted.

Three more steps make a data directory read-only for one request to
reach the failure paths after the files are accepted: storing extension
sources, storing the project JSON and saving the project record. They
answer 500 by design, so they are listed as expected errors.

checkGeneratedHistory cannot be reached offline: merge and restore
archives are built to match the stored history they are checked
against.